AppDirs package?

Admittedly, this looks very bad... but honestly, I cannot think of a good place to put it. Maybe the Desktop.java can handle more of such a path.

As for Appdirs (https://github.com/harawata/appdirs), I don't think it provides a method where I can get those common software package locations. It's true that maybe I can get the user data path and start just CD around, but at this point I should simply be hardcoding it anyway?

The example output they have here:

User data dir: C:\Users\ave\AppData\Local\harawata\myapp\1.2.3
User data dir (roaming): C:\Users\ave\AppData\Roaming\harawata\myapp\1.2.3
User config dir: C:\Users\ave\AppData\Local\harawata\myapp\1.2.3
User config dir (roaming): C:\Users\ave\AppData\Roaming\harawata\myapp\1.2.3
User cache dir: C:\Users\ave\AppData\Local\harawata\myapp\Cache\1.2.3
User log dir: C:\Users\ave\AppData\Local\harawata\myapp\Logs\1.2.3
User downloads dir: C:\Users\ave\Downloads\harawata\myapp\1.2.3
Site data dir: C:\ProgramData\harawata\myapp\1.2.3
Site data dir (multi path): C:\ProgramData\harawata\myapp\1.2.3
Site config dir: C:\ProgramData\harawata\myapp\1.2.3
Site config dir (multi path): C:\ProgramData\harawata\myapp\1.2.3
Shared dir: C:\ProgramData\harawata\myapp\1.2.3

I figured the best I can achieve based on this is to take the shared directory and user cache directory and start CD-ing?

Comment restates what is obvious from the code and doesn't provide additional value or reasoning. Such comments should be removed.

I assume if I remove this, you will say throwing an exception is discouraged and may interrupt the application...

Injected fields should be final to prevent accidental modification after initialization, following effective Java principles.

I don't think I could make this final without initializing this to null in the constructor?

Depends on how afterburner works. Please look for other places in code where this happen.

Nope, cannot be final

The method handles GUI validation logic directly in the dialog class instead of delegating to the ViewModel, violating the separation of concerns principle.

Method returns direct property value which could be null, contradicting @nonnull annotation. Should include null check or use Optional to properly handle potential null values.